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Abstract 

The  Coalition  Battle  Management  Language  [C-BML]  is  an  open  standard  being 
developed  for  the  exchange  of  digitized  military  information  among  command 
and  control  [€2),  simulation  and  autonomous  systems  by  the  Simulation 
Interoperability  Standards  Organization  (SISO].  As  the  first  phase  of  the  C-BML 
standard  nears  its  release,  the  Phase  2  Drafting  Group  (DG]  has  proposed  a 
framework  to  identify  and  track  the  concerns  and  requirements  to  be  addressed 
in  the  next  major  C-BML  standard  release. 

Following  this  proposition,  the  NATO  Modeling  and  Simulation  Group  085 
started  an  activity  to  put  into  place  a  prototype  engineering  process  for  the 
development  and  maintenance  of  a  unified  C2-SlMulation  [C2S1M]  Scenario 
INitialization  and  Execution  [SINEX)  Model.  As  part  of  this  activity,  the  group 
also  developed  a  draft  C2S1M  Distributed  Simulation  Engineering  and  Execution 
Process  [DSEEP]  Overlay  for  the  development  of  federations  comprised  of 
simulation  and  C2  systems.  The  current  paper  reports  on  these  activities  and 
also  provides  recommendations  for  the  integration  of  the  SINEX  Process  as  part 
of  a  unified  C2S1M  interoperability  standard  that  will  include  the  alignment  and 
convergence  between  the  Military  Scenario  Definition  Language  (MSDL]  and  C- 
BML. 

1  Introduction 

The  NATO  MSG-085  Technical  Activity  formed  a  series  of  Common  Interest  Groups  (CIG]  in 
early  2012  to  address  domain-specific  issues  for  the  Air,  Land  and  Maritime  domains.  The 
Requirements,  Recommendations  and  Specifications  (2RS]  CIG  also  was  formed  in  2012  to 
explore  the  viability  of  the  SINEX  approach  with  the  objectives  of  documenting  a  formal 
process  and  creating  a  prototype  production  chain  based  primarily  on  existing  COTS  tools 
and  those  made  available  by  the  Multilateral  Interoperability  Programme  [MIP]  Block  4 
Working  Group.  An  additional  objective  of  this  activity  was  to  create  a  draft  version  of  a 
DSEEP  Overlay  to  guide  the  use  of  the  derived  products  for  C2S1M  Federation  development. 

Following  this  introduction.  Section  2  describes  the  SINEX  approach  and  the  results  of  the 
2RS  CIG.  Section  3  describes  the  C2S1M  DSEEP  Overlay  drafted  by  the  2RS  CIG.  Section  4 
proposes  a  set  of  recommendations  for  future  work,  as  well  as  recommendations  for  the 
standardization  bodies.  Section  5  concludes  the  paper. 


2  SINEX  Approach 

This  section  provides  recommendations  for  the  standardization  of  the  Scenario 
INitialization  and  Execution  (SINEX]  model  based  on  the  work  conducted  by  the  MSG-085 
2RS  Common  Interest  Group.  In  related  previous  work,  the  SINEX  approach  has  been 
proposed  as  a  means  to  unify  the  SISO  Military  Scenario  Definition  Language  (MSDL]  and 
the  Coalition  Battle  Management  Language  (C-BML]  into  one  common  standard  based  on  a 
Systems  Engineering  best  practices  and  Model-driven  architecture  (MDA]  tools  developed 
in  collaboration  with  the  Multilateral  Interoperability  Programme  (MIP]  (see  [Heffner,  Bau 
&  Gerz  2013]  and  [Heffner  2013]].  The  SINEX  approach  is  consistent  with  the 
recommendations  of  the  SISO  C2SIM  Interoperability  Tiger  Team  Final  Report  (see  [SISO 
C2SIM  TIGER  TEAM  2014]]. 

SINEX  is  for  the  development  and  maintenance  of  interoperability  standards  based  on  the 
Standard  Development  Framework  (see  [Gupton  &  Heffner  2012]],  and  can  be  described  as: 

1.  A  formal  process  that  guides  the  standard  development  (see  [SINEX  Process 
Description  Document]];  and 

2.  A  highly  automated  production  chain  to  facilitate  the  elaboration  of  standards 
products  based  on  the  re-use  of  existing  tools  developed  by  the  MIP  (see  [Heffner, 
Bau  &  Gerz  2013]]. 

SINEX  address  the  issues  and  challenges  related  to  developing  and  evolving  technical 
interoperability  standards  in  general,  and  specifically  for  C2SIM  interoperability  (see 
[Heffner  &  Gupton  2013]].  The  main  output  of  the  SINEX  approach  is  the  creation  of  a 
Logical  Data  Model  (LDM]  that  is  largely  based  on  the  re-use  of  existing  model  elements 
such  as  classes,  enumerations  and  associations  from  the  MIP  Information  Model  (MIM].  The 
MIM  is  the  successor  to  the  Joint  Command  &  Control  Consultation  Information  Exchange 
Data  Model.  From  the  LDM  or  Platform  Independent  Model  (PIM]  in  MDA  terminology,  the 
Platform  Specific  Model  (PSM]  (e.g.  extensible  Markup  Language  (XML]  Schemas,  HLA 
FOMs,  DIS  PDUs  etc...]  are  generated  using  MDA  transforms. 

The  SINEX  approach  provides  several  advantages  compared  to  maintaining  a  monolithic 
model  using  an  XML  Schema-based  interface.  First,  SINEX  is  based  on  the  MIP  modular  sub¬ 
view  approach  and  thus  allows  for  building  models  with  small  footprints  to  meet  only  the 
C2SIM  interoperability  requirements  needed  for  a  specific  use  case.  Second,  this  allows  for 
maintaining  interoperability  with  other  systems  since  it  involves  the  use  of  a  common  base 
model  -  the  MIP  Information  Model  (MIM].  Finally,  the  fact  that  MIM  and  SINEX  are  based 
on  MDA  makes  the  C2SIM  interoperability  neutral  to  specific  interoperability  technologies. 
Thus,  it  allows  for  using  such  as  HLA  and  JSON. 

The  work  of  the  2RS  GIG  has  focused  on  finalizing  the  approach  and  defining  the  process. 
Also,  significant  effort  has  been  spent  on  producing  an  initial  prototype  production  chain 
that  already  provides  a  powerful  capability  and  shows  much  promise  for  continued  use  in 
future  related  technical  activities. 


2.1  Background 

The  SINEX  initiative  draws  from  two  bodies  of  work:  1)  The  MIP  Modular  Enterprise 
Architecture  Interoperability  Solution  as  described  by  [Lang,  Gerz,  Meyer,  Sim  2011];  and 
2]  the  Standards  Development  Framework  for  M&S  standards  elaborated  by  [Gupton  & 
Heffner  2012]  that  builds  upon  the  work  done  by  the  US  Intelligence  community  in  defining 
a  standard  for  information  storage  and  retrieval  [US  IC/DOD  2012]. 

The  MIP  solution  leverages  the  Model  Driven  Architecture  [MDA]  approach  and  focuses  on 
the  creation,  evolution  and  exploitation  of  a  PIM  that  is  a  formal  Logical  Data  Model  [LDM]. 
Lang  et  al  also  recognize  the  need  to  maintain  modularity  at  all  costs  and  thus  offer  the 
capability  to  those  wishing  to  reutilize  the  existing  MIP  model,  by  reusing  only  the  model 
elements  that  they  need  by  creating  "capability  packages”  or  "model  sub-views”. 

[Heffner  &  Gupton  2013]  describes  a  holistic  process  that  also  centers  on  the  LDM  while 
maintaining  a  strong  connection  with  stakeholder  requirements.  Consistent  with  the  MDA 
approach,  transforms  are  used  to  derive  products  from  the  SINEX  LDM  in  order  to  meet 
implementation  needs.  At  the  same  time,  this  approach  emphasizes  the  need  for 
extensibility.  Arguably  the  strongest  link  between  these  two  efforts  is  the  underlying 
requirement  for  SISO  C-BML  to  utilize  the  MIP  model  as  the  first  and  primary  source  of 
vocabulary. 

2.2  SINEX  Process 

The  SINEX  process  is  based  on  the  Systems  Engineering  iterative  Vee-model  adapted  for  the 
development  of  technical  interoperability  standards,  described  in  [SINEX  Process 
Description  Document].  The  strong  emphasis  on  requirements  management  is  consistent 
with  the  goal  of  achieving  traceability. 


FIGURE  1  -  SINEX  PROCESS  OVERVIEW 


The  model  definition,  model  generation  and  model  transformation  processes  correspond  to 
MDA  constructs,  while  the  verification  process  links  the  user  and  derived  requirements  to 
the  model  and  derived  products.  The  validation  process  is  intended  to  ensure  that 
stakeholder  requirements  have  been  successfully  captured  and  implemented.  This  may 
require  a  dedicated  test  environment  and  target  test  scenarios  and  is  an  area  of  future 
work. 

2.3  SINEX  Production  Chain  Prototype 

One  of  the  main  ideas  in  developing  the  SINEX  production  chain  was  to  make  maximum  re¬ 
use  of  existing  tools  and  in  particular,  those  provided  by  the  MIP  Block  4  Working  Group 
associated  with  the  development  of  the  MIM,  the  latest  MIP  model.  The  MIM  is  the  proposed 
successor  of  the  JC31EDM.  Based  on  the  MIP  tools,  the  SINEX  production  chain  also  utilizes 
the  Unified  Modeling  Language  (UML]  editing  tool  Sparx  System  Enterprise  Architect™ 
(EA)  to  specify,  manipulate  and  transform  the  model.  EA  also  has  features  for  requirements 
management  and  automatic  document  generation. 

The  SINEX  production  chain  is  implemented  as  an  environment  that  allows  for  the 
collaboration  of  various  actors  with  different  backgrounds  and  roles,  contributing  from 
different  locations.  Figure  2  is  an  overview  of  the  SINEX  workspace  and  shows  the  primary 
workflows.  Figure  3  is  a  screenshot  of  the  main  menu  of  the  prototype  that  was  developed 
as  a  first  implementation  of  the  SINEX  process  and  which  enables  the  work  flows  that  are 
identified  in  Figure  2.  Table  1  provides  a  brief  description  of  the  components  that  enable 
the  workflows  identified  in  Figure  3.  In  December  2013,  demonstrations  of  the  SINEX 
process  and  prototype  toolset  were  given  2013  as  part  of  the  NATO  Modelling  and 
Simulation  Group  activities  during  Interservice  Industry  Training  Simulation  and  Education 
Conference  [1/lTSEC). 


FIGURE  2  -  SINEX  WORKSPACE  OVERVIEW  EIGURE  3  -  SINEX  PROTOTYPE  MAIN  MENU 

The  demonstration  included  the  requirements  definition  step  for  a  C2S1M  interoperation 
sub-model  to  communicate  an  obstacle  report,  followed  the  model  definition  of  a  sub-model 
based  on  existing  model  elements  from  the  MIM  [e.g.  types,  enumerations,  associations 
etc.).  Also,  additional  model  elements  were  defined  and  added  to  the  model  as  per  the 
requirements.  As  part  of  the  model  definition  process,  a  drag-and-drop  functionality 
allowed  to  create  links  between  requirements  and  the  specified  model  elements,  thus 
allowing  for  traceability  of  requirements.  Then  a  UML  model  was  created  as  part  of  the 


model  generation,  including  automatically  generated  UML  diagrams.  In  the  next  step,  model 
transformation,  an  XML  schema  was  created  using  a  fully  automated  UML  transform.  The 
verification  step  allows  for  the  user  to  rapidly  determine  which  requirements  have  been 
satisfied  and  by  which  model  elements.  Also,  developers  can  access  the  requirements 
associated  with  a  specific  model  elements  and  derived  products  such  as  XML  schemas  and 
thus  are  better  able  to  understand  the  intended  use  and  limitations  of  these  products. 

This  demonstration  highlighted  an  important  aspect  of  the  SINEX  approach  in  that  the  user 
is  not  required  to  have  any  UML  experience.  The  tools  present  an  interface  that  is  intended 
for  a  broad  range  of  users  and  therefore  require  limited  prior  knowledge.  At  the  same  time, 
advanced  users  can  access  the  UML  workspace  for  greater  detail  concerning  the  models. 
However,  data  modeling  is  a  difficult  task  and  therefore  performing  the  model  definition 
step  should  be  restricted  to  a  limited  set  of  users.  Nonetheless,  minor  modifications  to 
existing  models  can  be  introduced  by  any  user. 

TABLE  1  -  SINEX  PRODUCTION  CHAIN  COMPONENT  SUMMARY 


COMPONENT 

DESCRIPTION 

Requirements  Editor 

Allows  user  to  enter  requirements  into  a  workspace  as  per  SINEX  Requirements 

Management  Process,  based  on  the  NATO  Architecture  Framework  (NAF). 

Requirements  can  reference  external  sources  or  other  requirements. 

Requirements  have  unique  ID  used  for  traceability  purposes. 

Model 

Editor 

Allows  the  user  to  generate  or  revise  Model  Definition  Packages  (for  Major  Model 

Revisions)  and  also  to  generate  Change  Proposals  (for  Minor  Model  Revisions).  The 
outputs  of  the  editor  are  XML  files  that  are  used  as  inputs  for  the  fully  automated  Model 
Processor. 

The  editor  also  can  generate  RTF  and  HTML  documents  for  Model  Definition  Packages 
and  Change  Proposal  to  facilitate  the  review  process. 

Model 

Processor 

The  Model  Processor  h2is  two  modes:  1)  model  creation  mode;  and  2)  model  revision  mode. 
Model  creation  mode  requires  a  model  definition  package  that  may  reference  a  model  that 
has  been  imported.  The  output  of  the  Model  Processor  is  a  SINEX  LDM. 

Model  revision  mode  requires  an  existing  SINEX  LDM  and  a  set  of  Change  Proposals. 

Model 

Importer 

The  Model  Importer  can  import  OWL  Ontologies,  XML  Schemas  and  UML  models  such 
that  they  can  be  referenced  by  the  requirements  interface  and/ or  by  the  model  editor.  This 
allows  for  re-use  of  existing  models  in  several  manners:  1)  direct  re-use  of  data  elements  as 
part  of  SINEX  LDM;  2)  reference  to  existing  data  element  for  the  purposes  of  subsequent 
translation  and  mapping. 

Document  Generator 

Allows  for  the  automatic  creation  of  documents  based  on  the  SINEX  Workspace  Package 
Structure.  Document  generation  formats  include  HTML,  RTF  and  PDF.  Document 
content  is  based  on  information  and  diagrams  comprising  the  SINEX  Requirements  Model 
and  LDM,  including  inputs  entered  using  the  Requirements  Interface  and  the  Model  Editor. 

Model 

Exporter 

The  Model  Exporter  is  based  on  the  Model  Driven  Architecture  approach  and  consists  of  a 
set  of  Model  Transforms: 

In  the  short  term:  1)  UML^XSD;  2)  UML^HLA-FOM;  and  subject  to  future  research: 

3)  UML^  JSON  ;  4)  UML^  OWL;  5)  UML^  EBNF. 

The  Model  Export  ensures  that  the  various  SINEX  outputs  or  PSM  representations  are 
consistent  and  that  they  readily  can  be  generated  following  a  SINEX  LDM  major  or  minor 
revision. 

3  C2SIM  DSEEP  Overlay 

Interoperability  between  Command  and  Control  [C2)  and  simulation  systems  involves 
bridging  two  separate  worlds.  The  simulation  community  uses  mature  standards  for 
building  simulation  federations,  such  as  High  Level  Architecture  (HLA]  and  Distributed 


Interactive  Simulation  [DIS].  The  C2  community  interacts  within  an  operational 
environments  and  uses  a  variety  of  standards  such  as  formatted  messages  such  as  NATO 
Allied  Data  Publication  3  [ADatP-3),  data  links  (e.g.  Link  16),  information  exchange  data 
models  such  as  the  JC3IEDM  and  different  kinds  of  transport  mechanisms  according  to 
operational  requirements. 

Thus,  a  C2SIM  environment  or  federation  requires  bridging  several  environments  and 
architectures.  Figure  1  shows  a  typical  architecture  used  by  MSG-085,  involving  both  C2IS 
and  simulation  systems  interoperating  using  C-BML.  Note  that  the  C-BML  does  not 
prescribe  a  specific  middleware  or  transport  mechanism  to  implement  communication 
among  the  systems.  The  integration  of  simulation  systems  in  a  C2  environment  represents 
additional  challenges.  C2  systems  are  typically  designed  to  operate  in  a  real-time 
environment  with  limited  information  available  (e.g.  reports  from  subordinates). 
Constructive  simulations  can  generate  a  lot  of  information  not  available  in  a  real  tactical 
environment  and  can  run  faster  than  real-time.  Another  important  topic  that  needs 
consideration  is  the  common  initialization  of  C2  systems  and  simulations,  e.g.  using  MSDL. 


FIGURE  4:  TYPICAL  C2-SIMULATION  ARCHITECTURE 


C 

2 

N 

e 

t 

w 

o 

r 

k 


SISO  and  IEEE  have  developed  a  set  of  recommended  practices  for  defining  and  developing 
distributed  simulation  environments  comprised  of  systems  that  may  use  different 
simulation  protocols.  The  DSEEP,  shown  in  Figure  4,  provides  a  framework  for  defining, 
constructing  and  executing  distributed  simulations.  DSEEP  overlays  are  defined  to  tailor  the 
DSEEP  for  specific  applications  or  use  cases.  Overlays  have  already  been  provided  for  HLA, 
DIS  and  Distributed  Multi  Architectures  [DMA)  (see  [IEEE  1730™  2010]  and  [IEEE  1730.1™ 
2013]). 


IEEE  Std  1730-2010 

IEEE  Reccm mended  Preetiee  fer  Distributed  Simulation  Engineering  and  Execution  Process  (DSEEP) 


FIGURE  5:  DSEEP  TOP-LEVEL  PROCESS  FLOW  VIEW  (TAKEN  FROM  [IEEE  1730tm  2010]) 


The  C2SIM  DSEEP  Overlay  is  intended  to  help  the  user  community  better  understand  how 
C2S1M  interoperability  standards  should  be  used  to  support  [distributed)  simulation 
environments  that  are  connected  to  or  part  of  a  larger  C2S1M  federation. 

The  purpose  of  the  work  presented  is  to  initiate  a  C2S1M  DSEEP  Overlay.  The  major 
elements  of  this  draft  DSEEP  Overlay  are  described  in  the  following  sections. 

3.1  DSEEP  Overview  and  Terminology 

The  C2S1M  DSEEP  Overlay  describes  recommended  practices  for  applying  DSEEP  to  the 
development  and  execution  of  distributed  simulation  environments  that  involve  one  or 
more  C2  systems  used  to  command  and  control  autonomous  and  simulated  entities. 

The  two  main  contributions  of  the  C2S1M  DSEEP  Overlay  are: 

•  A  description  of  issues  and  recommendations  related  to  the  definition,  development 
and  execution  of  a  federation  of  C2  and  simulation  systems. 

•  A  description  of  the  additional  inputs,  tasks  and  outcomes  for  each  of  the  seven 
DSEEP  steps  [see  [IEEE  1730™  2010]). 


Figure  6  depicts  a  typical  training  system  that  is  comprised  of:  several  cells  [LOGON, 
Training  Audience  and  HlCON)i  equipped  with  C2  systems;  and  one  [or  more)  simulation 
system[s). 
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FIGURE  6:  EXAMPLE  OF  A  TRAINING  SYSTEM 

For  the  C2S1M  DSEEP  Overlay,  the  following  terms  are  defined  consistent  with  [IEEE  1730™ 
2010]  and  [IEEE  1730.1™  2013]: 

•  Simulation  environment:  generic  term  as  defined  in  [IEEE  1730™  2010]  and  [IEEE 
1730.1™  2013],  it  includes  LVC  simulations  including  all  Live  assets  which  are 
connected  together  with  a  common  Simulation  Data  Exchange  Model  [SDEM); 


1  Low  Control;  High  Control; 


•  C2SIM  federation:  a  simulation  environment  that  contains  at  least  one  C2  system, 
and  that  uses  a  C2S1M  data  exchange  model  as  the  SDEM; 

•  Operational  environment:  a  set  of  connected  C2  systems  that  exchange  operational 
data. 

The  C2S1M  federation  defines  the  system  boundary  for  the  C2S1M  DSEEP  Overlay.  The 
C2S1M  federation  also  can  be  combined  with  other  simulation  federations,  as  required.  The 
architecture  shown  in  Figure  6  also  is  an  example  of  a  Distributed  Multi-Architecture  (DMA) 
and  the  corresponding  overlay  or  DMAO  (see  [IEEE  1730.1™  2013])  should  be  used  in 
conjunction  with  the  C2S1M  DSEEP  overlay. 

The  C2S1M  DSEEP  Overlay  deals  only  with  the  practices  relevant  to  the  development  and 
execution  of  a  C2S1M  federation,  and  not  with  concerns  related  to  a  C2S1M  federation 
combined  with  other  simulation  architectures  such  as  HLA  or  DIS;  these  cases  should  be 
considered  in  the  DMAO.  The  DMAO  is  already  applicable  to  C2S1M  federations  since  the 
combination  of  C2  and  simulation  systems  raises  multi-architecture  issues.  All  DSEEP  steps 
containing  "simulation  environment"  (or  "simulation”)  are  thus  renamed  "C2S1M 
federation"  (or  "C2S1M”)  for  the  purpose  of  the  C2S1M  DSEEP  overlay,  to  avoid  confusion 
with  other  simulation  environments. 

3.2  Issues^ 

The  list  of  major  issues  identified  is  as  follows: 

•  Stakeholders  include  individuals  from  both  C2  and  simulation  communities 

•  Time  management 

•  End-users’  perception  of  federation  execution 

o  Report  processing 
o  Order  processing 

Some  of  the  major  issues  are  further  described  in  the  following  sections  but  due  to  space 
limitations  other  major  issues  that  have  been  addressed  as  part  of  this  work  are  not 
reported  in  this  paper,  such  as:  the  preparation  of  scenario  to  initialize  the  federation  (e.g. 
objects,  events  and  terrain);  security  of  C2  systems;  C2S1M  architecture,  infrastructure 
services  and  data  exchange  model. 


3.2.1  Stakeholders  include  individuals  from  both  C2  and  simulation 
communities 

The  DSEEP  process  involves  two  communities  of  stakeholders:  C2  stakeholders  and 
simulation  stakeholders.  The  involvement  of  both  communities  throughout  the  process  is 
mandatory  to  meet  the  end-users  needs. 


2  Issue-,  a  concern,  such  as  a  situation  within  a  development  process  or  a  technical  element  of  an  architecture, 
from  which  obstacles  to  achieving  the  objectives  of  the  simulation  environment  may  arise  [DMAO]. 


Because  of  the  operational  constraints,  the  potentially  limited  availability  of  valuable  C2 
system  resources  should  be  considered  as  part  of  the  C2S1M  federation  planning.  For 
example,  the  availability  of  C2  systems  experts  and  other  subject  matter  experts  [SME] 
should  be  taken  into  account  when  the  work  breakdown  structure  is  developed  within 
Activity  1.3:  Conduct  initial  planning  (e.g.  design,  install,  configuration  and  operators].  The 
same  applies  to  the  availability  of  the  C2  systems  themselves.  Also,  some  contingency  plans 
could  be  prepared  to  reduce  risks. 

3.2.2  Time  management 

What  distinguishes  simulation  systems  from  most  other  types  of  systems  is  the  necessity  to 
manipulate  and  manage  time.  This  is  a  challenge  when  integrating  with  systems  that  are 
designed  to  use  only  wall-clock  time.  To  address  this  issue,  two  categories  of  use  cases  are 
considered: 

•  Training  use  cases,  which  mainly  involve  real-time  [RT]  simulations; 

•  Planning  use  cases  (e.g.  course  of  action  (CoA)  analysis],  which  mainly  involve  faster 
than  real-time  [FTRT]  simulations. 

In  training  use  cases,  end-users  use  the  C2  systems  to  monitor  and  control  an  ongoing 
(simulated]  operation.  This  involves  exchanging  messages  for  situation  awareness  and  to 
issue  orders.  Usually  C2  systems  make  assumptions  about  the  time  specified  in  messages, 
and  can  refuse  to  process  data  time  stamped  with  a  future  time.  In  a  C2S1M  federation,  the 
current  tactical  situation  is  computed  by  a  simulation,  but  the  logical  time  may  be  different 
than  the  wall-clock  time.  Normally,  for  the  purposes  of  training,  RT  simulation  are  used,  but 
FTRT  simulation  also  can  be  used,  (e.g.  to  focus  on  specific  phases  of  an  operation].  As  a 
consequence,  training  use  cases  will  require  synchronization  of  time  among  systems  of  the 
C2S1M  federation. 

In  planning  use  cases,  simulations  are  used  in  several  ways: 

•  The  end  user  observes  the  simulated  tactical  picture  as  it  unfolds  on  his  C2  system; 

•  The  end  user  brings  up  the  tactical  picture  on  a  C2  system  for  a  specific  point  in  time; 

•  The  simulated  tactical  picture  is  not  displayed  on  the  C2  system;  the  end  user  uses 
analysis  tools  of  the  simulation  system. 

The  last  case  doesn't  require  exchange  of  reports  between  C2  system  and  simulations.  The 
two  first  require  that  reports  are  properly  time-stamped.  As  a  consequence,  planning  use 
cases  might  not  require  synchronization  of  time  among  systems  across  the  C2S1M 
federation,  but  may  only  require  that  messages  and  data  exchanged  are  properly  time- 
stamped. 

From  a  system  perspective,  time  management  is  different  for  C2  and  simulation  systems. 
Usually,  C2  systems  are  locked  to  the  current  real-world  time,  whereas  simulations 
manipulate  time  as  a  variable. 


Most  C2  systems  can  manage  several  tactical  pictures  simultaneously.  But  it  is  generally  not 
possible  to  display  data  for  events  occurring  in  the  future  and  that  result  from  a  CoA 
analysis  or  mission  rehearsal.  As  a  consequence,  a  message  generated  by  a  simulation  and 
retrieved  by  a  C2  system  may  be  processed  differently  depending  on  the  purpose. 

The  objectives  (Activity  1.2:  Develop  objectives]  and  the  simulation  environment 
requirements  (Activity  2.3:  Develop  C2S1M  environment  requirements]  differ  according  to 
the  end  user  needs  and  use  case  category.  It  is  also  possible  that  some  end  user  needs  might 
require  both  categories  of  use  cases  (e.g.  planning  during  training].  The  objectives  need  to 
take  into  account  the  constraints  and  capabilities  of  the  systems  involved  (mainly  end 
users’  C2  systems],  and  possible  adaptations  or  extensions. 

For  training  use  cases,  the  following  questions  may  help  to  define  the  time  management 
objectives,  requirements  and  assess  their  feasibility: 

•  Will  the  exercise  time  be  less  or  equal  to  the  real-world  time  (e.g.  24/7  training]? 

•  During  training,  are  there  "pause"  periods  or  "accelerated"  periods? 

•  How  does  the  C2  system  build  its  current  situation  and  manage  time? 

o  Are  data  /  messages  verified  against  computer  time? 

o  Is  old  information  recorded  (and  used  for  later  playback],  or  is  only  the  last 
known  information  recorded? 

For  planning  use  cases,  the  following  questions  may  help  to  define  the  time  management 
objectives,  requirements  and  assess  their  feasibility: 

•  Is  the  C2  system  able  to: 

o  store  and  display  a  snapshot  of  future  tactical  picture  ? 

o  store  and  display  future  simulated  tactical  picture  as  it  unfolds  ? 

•  Is  there  a  need  to  execute  an  order  several  times,  e.g.  evaluation  of  different  CoAs  or 
evaluation  of  different  aspects  of  the  same  CoA? 

In  the  two  DSEEP  activities  (Activity  1.2:  Develop  objectives]  and  (Activity  2.3:  Develop 
C2S1M  federation  requirements]  distinguishing  the  following  options  may  be  helpful. 

Present  day  solution  (training  use  cases  only]: 

A  common  time  reference  should  be  decided  before  the  execution  of  the  use  case.  In 
this  case,  no  modification  of  the  C2  system  is  required,  but  it  should  be  configured 
properly.  It  can  be  assumed  that  the  simulated  time  will  never  be  greater  than  the  C2 
system  time.  If  the  simulation  is  paused,  the  C2  systems  will  receive  information  in 
the  past,  and  the  end  user  might  modify  some  filtering  options  to  display  older 
information  on  its  C2  system. 

Short  term  solution  (training  use  cases  only]: 

Time  translation  can  be  managed  by  the  infrastructure.  The  data  generated  by  a 
simulation  (at  a  time  Tsim]  can  be  modified  before  it  is  received  by  the  C2  systems 
(Tc2  =  Tsim  +  At],  so  that  Tcz  is  equal  to  the  system  time  in  the  C2  environment.  At 
could  be  managed  by  the  infrastructure  and  most  likely  automatically.  But  during 
the  execution  of  such  a  federation,  all  people  should  be  well  aware  of  the  At  and  its 
modifications. 


Long  term  solution: 

The  C2  systems  should  be  modified  to  manage  for  example  a  Nominal  mode  (for  live 
operations],  a  Training  mode  and  a  Planning  mode,  each  one  managing  the  time  of 
incoming  messages  differently.  On  the  C2  system,  the  main  difference  between  the 
Nominal  mode  and  the  Training  mode  is  the  management  of  the  time  of  the 
operation  (locked  to  the  C2  system  time,  or  controlled  by  the  C2S1M  federation]. 
Infrastructure  should  then  implement  common  time  coordination  services  across 
both  C2  and  simulation  systems. 

3.2.3  End-users'  perception  of  federation  execution 

This  section  describes  issues  related  to  the  processing  and  display  of  information  from  the 
simulation  environment  on  the  end-users’  C2  systems  and  thus  of  the  messages  and  data 
exchanged  during  C2S1M  federation  execution.  The  issues  concern  various  DSEEP  activities 
from  scenario  definition  to  scenario  execution  involving  a  C2S1M  federation. 

Message  Processing:  Reports 

There  are  several  issues  related  to  the  flow  of  information  included  in  reports  sent  from 
simulations  to  C2  systems: 

•  Level  of  detail  required  by  end-user  and/or  C2  system-.  For  instance,  a  simulation  can 
generate  observation  reports  about  aggregated  platoons,  whereas  the  trainees,  e.g. 
at  the  battalion  level  should  receive  individual  vehicles  reports.  This  can  occur  when 
a  simulation  designed  to  train  brigades  is  also  requested  and  used  to  train  battalions 
(battalions  being  the  first  level  of  command  with  an  intelligence  cell,  they  receive 
vehicles  reports,  merge  them,  and  send  platoons  reports]. 

•  Simulation  information  filtering:  Simulations  are  capable  of  generating  a  wide  range 
of  information.  However,  the  C2  systems  may  only  need  a  subset  of  this  information, 
depending  on  their  role  and  capabilities.  Thus  C2  systems  or  gateways  should  only 
process  reports  that  are  required  for  a  specific  function  or  purpose.  This  may 
require,  for  instance,  a  filtering  mechanism: 

o  A  C2  system  attached  to  a  particular  unit  should  only  process  reports  that  are 
sent  to  this  unit; 

o  A  C2  system  used  as  by  EXCON^  to  have  a  "God’s-eye  view”  of  the  situation 
needs  to  be  capable  of  managing  several  information  layers  or  tactical 
pictures  simultaneously. 

•  Ground  truth  and  Perceived  truth:  Simulations  are  capable  of  generating  information 
dealing  with  both  ground  truth  and  perceived  truth  while  for  C2  systems,  it  depends 
on  the  application.  For  example,  C2  systems  used  for  training  should  only  receive 
information  derived  from  the  perceived  truth,  ie.  from  measurements  of  the  real 
world  (sometimes,  eg  in  the  case  of  blue  force  tracking,  in  a  very  simple  model  of  the 
real  world  ground  truth  can  be  used  as  an  approximation  of  GPS  measurements].  For 
the  purposes  of  mission  planning,  both  ground  truth  and  perceived  truth  are 
relevant. 


3  Exercise  Controller 


•  Simulation  information  overload:  The  rate  of  messages  produced  by  simulations  can 
be  much  greater  than  typical  message  exchanges  occurring  within  the  operational 
environment.  Therefore,  it  may  be  required  to  apply  limits  and  restrict  the  rate  at 
which  reports  are  exchanged  since  C2  systems  may  not  always  be  able  to  process 
and  display  all  of  the  information  produced  by  simulations.  Two  options  to  address 
this  issue  are: 

o  Infrastructure  or  gateways  can  perform  filtering  by  limiting  report  rates  or  by 
creating  aggregate  reports  that  include  several  single  unit  reports, 
o  The  simulation  can  be  modified  to  restrict  the  flow  of  reports. 

Message  Processing:  Orders  and  Requests 

Similar  to  the  processing  of  reports,  there  are  several  issues  related  to  the  flow  of 
information  included  in  orders  and  requests  sent  from  C2  systems  to  simulations: 

•  Orders  and  tasks  generated  by  C2  systems  may  not  be  executable  by  simulations 
because  they  may  require  behaviours  that  are  not  available  in  the  simulation  models. 
Also  the  simulation  interface  may  not  recognize  the  tasking  verbs  specified  in  the 
order.  In  addition,  simulations  may  require  different  parameters  for  a  given  task 
[e.g.  a  route  or  a  phase  line).  To  resolve  this  issue,  it  is  possible  to  extend  simulation 
interfaces  or  adapt  behaviour  models.  Alternately,  it  is  possible  to  constrain  the 
orders  produced  by  C2  systems  in  order  to  be  consistent  with  simulation 
requirements. 

•  Orders  generated  by  a  C2  system  reflect  specific  doctrine  that  may  or  may  not  be 
consistent  with  simulation  behaviours. 

To  address  the  issues  described  above,  the  authors  propose  the  following 
recommendations: 

•  System  Capabilities  Descriptions:  C2  systems,  simulations,  gateways  ...  should  provide 
their  capabilities  using  a  common  format  and  make  this  available  through  a  M&S 
repository  [e.g.  simulation  behaviours,  C2S1M  information  exchange  capabilities,  C2 
system  report  consumption  limits,  etc...) 

•  System  Interface  Descriptions:  Each  C2S1M  federate  interface  should  provide  a 
description  of  its  information  exchange  capabilities.  For  example,  the  interface 
description  could  specify  the  unit  types  that  can  manage  a  specific  task  along  with  a 
set  of  parameters,  (e.g.  location,  boundaries,  objectives,  phase  lines,  supporting 
unit...). 

•  System  Mediation:  Gateways  could  be  used  to  satisfy  requirements  for  aggregation 
and  disaggregation  of  reports  and  controlling  message  exchange  rates. 


4  Recommendations 


4.1  Use  of  SINEX  Process  for  Technical  Interoperability  Standard 
Development 

The  SINEX  initiative  has  produced  a  draft  process  for  the  standardization  of  C2SIM 
interoperation  for  initialization  and  execution  of  C2SIM  federations.  This  process  addresses 
the  issues  and  challenges  that  have  been  identified  by  previous  technical  standard 
interoperability  efforts  and  proposes  a  means  to  maintain  the  link  between  stakeholders 
and  standard  developers.  SINEX  proposes  an  iterative  process  and  is  based  on  systems 
engineering  best  practices.  It  includes  the  means  to  ensure  traceability  of  requirements  for 
the  benefit  of  both  those  issuing  the  requirements  and  those  implementing  the  standard 
and  this  is  an  aspect  that  has  been  identified  as  essential  for  the  developing,  evolving  and 
applying  technical  interoperability  standards  for  the  C2SIM  interoperation  as  well  as  other 
domains. 

4.2  Use  of  SINEX  for  C2SIM  Interoperability  Standard  Development 

Based  on  the  work  presented  in  this  paper  and  consistent  with  the  SISO  C2SIM  Tiger  Team 
Recommendations  Report,  the  authors  make  the  following  recommendations: 

•  Consistent  with  the  initial  product  nominations  for  C-BML  and  MSDL,  these 
standards  should  be  merged  into  a  unified  standard; 

•  This  unified  standard  should  be  developed  and  maintained  using  a  formal  process 
such  as  proposed  SINEX  Process; 

•  The  unified  standard  should  be  based  on  a  formal  model; 

•  Consistent  with  the  C-BML  product  nomination  and  the  use  of  the  JC3IEDM  in 
existing  MSDL  and  C-BML  standards,  the  model  should  be  built  upon  the  MIP 
Information  Model,  as  the  principal  source  of  vocabulary; 

•  The  model  should  be  built  using  a  highly  automated  production  chain  to  accelerate 
the  development  and  subsequent  evolution  of  standards  products  while  avoiding 
human-induced  error; 

•  The  production  chain  should  reuse  the  MIP  tools  as  much  as  possible; 

•  The  development  of  the  unified  standard  should  be  grounded  in  user  requirements 
and  these  must  be  traceable  throughout  the  standard  development  process. 

NATO  Science  and  Technology  Organization  Technical  Activities  such  as  MSG-048,  MSG-085 
and  MSG-106  have  played  a  key  role  in  evaluation  standards  and  providing  feedback  to  the 
standards  communities.  Therefore,  the  further  development  of  the  unified  standard  should 
include  continued  involvement  of  NATO  technical  activities  and  thus  pave  the  way  for 
adoption  of  the  unified  standard  as  a  NATO  STAndardized  AGreement  [STANAG].  A  draft 
proposal  for  a  follow-on  technical  activity  to  MSG-085  to  operationalize  C2SIM 
interoperation  has  been  made  and  currently  is  being  reviewed  by  NATO  nations.  As  part  of 
this  activity  the  SINEX  process  and  tools  could  be  used  as  a  means  to  contribute  to  the 
establishment  of  a  unified  model  and  operationally  relevant,  usable,  technically  sound 
C2SIM  interoperability  standard. 


4.3  SINEX  Future  work 

The  SINEX  Initiative  has  made  significant  progress  under  the  MSG-085  Technical  Activity, 
however  work  remains  to  finalize  the  process  and  to  complete  the  tool  set.  The  process 
must  be  reviewed  by  a  broader  community  and  possibly  refined  to  meet  organizational 
requirements  such  as  those  related  to  the  SISO  standard  development  processes. 

Although  an  initial  set  of  requirements  for  C2SIM  interoperability  has  been  proposed,  these 
requirements  should  be  reviewed,  refined  and  complemented,  as  required. 

Recently,  the  MIP  has  developed  a  tool  called  the  Message  Builder  that  allows  the  user  to 
quickly  develop  XML  schemata  for  messages  constructed  from  existing  model  elements.  The 
Message  Builder  is  consistent  with  the  initial  vision  of  the  Message  Framework  as  reported 
by  [Heffner  &  Gupton  2013].  This  tool  complements  the  current  SINEX  tool  chain  and  thus 
should  be  considered  for  future  versions  of  SINEX. 

As  per  the  C-BML  product  nomination  (see  [SISO  C-BML  PN]],  future  applications  of  a 
unified  C2SIM  interoperability  standard  likely  will  require  the  exchange  of  semantics 
associated  with  the  data  elements  of  the  information  products  that  are  exchanged  (i.e. 
messages].  This  will  require  the  development  of  ontology  products  such  as  Web  Ontology 
Language  (OWL]  modules  as  part  of  the  standard  development  process.  Initial  work  in  this 
area  already  has  been  conducted  in  collaboration  with  the  MIP,  but  more  work  is  needed. 

4.4  DSEEP  Overlay  future  work 

The  MSG-085  2RS  GIG  has  made  an  initial  effort  for  a  C2SIM  DSEEP  Overlay.  Additional 
work  is  required  and  should  be  extended  to  the  larger  community  that  could  include 
participation  from  NATO  and  SISO: 

•  Elaborate  on  the  issues  that  have  been  identified;  provide  additional  details 
concerning  the  C2SIM  DSEEP  steps  (e.g.  activity  inputs,  tasks  and  outcomes] 

•  Define  a  C2SIM  reference  architecture. 


5  Conclusions 

The  results  and  findings  of  the  MSG-085  technical  activity  have  allowed  for  significant 
progress  in  establishing  a  sustainable  means  for  developing  and  evolving  a  C2 -Simulation 
Interoperability  standard  for  sharing  military  information  across  C2  and  simulation 
systems  for  various  military  enterprise  activities. 

The  initial  C2SIM  DSEEP  Overlay  that  has  been  drafted  captures  the  experience  and  lessons 
learned  from  experimentation  activities  that  included  building  and  executing  C2SIM 
federations.  The  SINEX  draft  process  and  prototype,  along  with  the  initial  C2SIM  DSEEP 
Overlay  form  a  strong  foundation  for  guiding  future  C2SIM  interoperability  standardization 
activities  within  NATO  and  SISO. 
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Presentation  Overview 


►  Introduction;  the  2RS  CIG 

►  SINEX  Approach 

►  C2SIM  DSEEP  Overlay 

►  Recommendations 

►  Conclusions 


NOTE:  This  is  about  capabilities,  not  experiments. 
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The  2RS  CIG 


ICCRTS’1 4-074 


3 


SINEX,  DSEEP  and  the  2RS  CIG 


►  NATO  MSG-085  created  a  prototype  engineering  process  to 
develop  and  maintain  a  unified  C2-SIMulation  (C2SIM)  Scenario 
INitialization  and  Execution  (SINEX)  Model 

►  The  Requirements,  Recommendations  and  Specifications  (2RS) 
Common  Interest  Group  (CIG)  is  documenting  a  formal  process 
and  creating  a  prototype  production  chain 

°  Re-use  of  existing  COTS  tools  and  tools  made  available  by 
the  Multilateral  Interoperability  Programme  (MIP)  Block  4  WG 

°  Additional  objective:  create  a  draft  version  of  a  SISO  DSEEP 
Overlay  to  guide  the  development  of  C2SIM  Federations. 
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SINEX  Approach 
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Standardizing  SINEX 


►  Based  on  a  Systems  Engineering  best  practices 

►  Utilizes  Model-driven  architecture  (MDA)  tools 
developed  by  the  MIP 

►  The  SINEX  approach  has  been  proposed  as  a  means 
to  unify  into  one  common  standard: 

°  SISO  Military  Scenario  Definition  Language  (MSDL) 

°  SISO  Coalition  Battle  Management  Language  (C-BML) 
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SINEX  Key  elements 


►  To  develop  interoperability  standards  based  on  the  Standard 
Development  Framework  (SDF)  of  Heffner  &  Gupton  201 3 

»  Formal  process  guides  standard 

»  Highly  automated  production  chain  for  standards  based  on  the  re¬ 
use  of  existing  tools  developed  by  the  MIP 

►  Focus  on  core  Logical  Data  Model  (LDM)  largely  inspired  by 
existing  MIP  Information  Model  (MIM) 

»  MIM  is  the  successor  to  the  JC3IEDM 

►  MDA  Transforms  to  generate  Platform  Specific  Model  (PSM) 

»  XML  Schemas,  HLA  FOMs,  DIS  PDUs,  JSON  etc... 
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Why  SINEX? 

►  Advantages  over  previous  MSDL/C-BML  Approaches 

°  Provides  for  modularity  compared  to  huge  monolithic  model 

•  Uses  MIP  modular  sub-view  approach 

•  Can  easily  build  models  with  small  footprints  for  specific  uses 

°  Easier  to  understand  documented  UML  model  compared  to 
previous  XML  Schema  representation 

°  Easier  to  maintain  and  evolve  since  core  model  is  based  on 
MIM  standardized  coalition  C2  interoperability  standard. 

°  Technology  agnostic,  since  MDA  approach  can  generate 
various  representations  of  LDM  using  transforms. 

•  E.g.  HLA,  JSON, 


Initial  prototype  production  chain  created 
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SINEX  Process  Overview 


SINEX  Production  Chain  Prototype 
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Creation  of  a  SINEX  EA  workspace 


Creation  of  a  SINEX  Tool 


MAIN  MENU 


Scenario  INitialization  &  Execution 

Standardization 


SINEX 


Model 

Definition 


Model  I 
T  ransformation 
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Prototype  Toolset  Demonstration 


►  SINEX  toolset  demonstrated  in  NATO  booth  at 
l/ITSEC  2013 

°  Requirements  definition 

°  Model  definition  of  a  sub-model  based  on  MIM  elements 

•  Including  drag-and-drop  of  additional  elements 
°  Model  generation 

•  Including  automatically  generated  UML  diagrams 
°  Model  transformation 

•  Fully  automated  XML  schema  generation 

►  Using  SINEX  tool  requires  no  UML  experience 

►  Prototype  is  not  yet  publicly  available 


DSEEP  Overlay 
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C2SIM  Interoperation 


►  C2-Simulation  Interoperability  requires  bridging 
two  separate  worlds 

»  The  simulation  community  uses  standards  for  building 
simulation  federations 

•  High  Level  Architecture  (HLA) 

•  Distributed  Interactive  Simulation  (DIS) 

o  The  C2  community  interacts  within  operational 
environments  using  a  variety  of  standards 

•  Formatted  messages  such  as  NATO  Allied  Data 
Publication  3  (ADatP-3) 

•  Data  links  (e.g.  Link  16) 

•  Information  exchange  data  models  such  as  the  JC3IEDM 


C2SIM  interoperation  requires  bridging  these 
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Typical  C2-Simulation  Architecture 

and  main  challenges 
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DSEEP  and  overlays 


IEEE  Std  1730-2010 

IEEE  Recommended  Practice  for  Distributed  Simulation  Engineering  and  Execution  Process  (DSEEP) 
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CoiiKliv  e  AcliOits  f  llesive  D  evelofmeiTri 


►  DSEEP:  existing  IEEE  and  SISO  recommendations  to 
define  and  execute  distributed  simulations 

►  Already  existing  overlays  (layers):  HLA,  DIS,  DMAO 


DMAO:  DSEEP  Multi  Architecture  Overlay 
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C2SIM  DSEEP  Overlay 


IEEE  Std  1730-2010 

IEEE  Recommended  Practice  for  Distributed  Simulation  Engineering  and  Execution  Process  (DSEEP) 
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Propose  a  C2SIM  DSEEP  overlay  for  this  process: 

•  to  aid  the  engineering,  the  execution  and  the  analysis  of 
distributed  simulation  environments  containing  C2  systems 
”  to  help  user  community  better  understand  how  C2-simulation 
interoperability  standards  (C-BML  /  MSDL)  are  intended  to  be 
used 
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Overlay  overview 


►  Main  contributions  of  the  C2SIM  DSEEP  Overlay: 

°  Description  of  issues  and  recommendations  related  to 
the  definition,  development  and  execution  of  a 
federation  of  C2  and  simulation  systems 
°  Description  of  the  additional  inputs,  tasks  and 
outcomes  for  each  of  the  seven  DSEEP  steps 

►  C2SIM  DSEEP  Overlay  deals  only  with  C2-Simulation 
issue,  not  simulation  federation  issues 


Example  of  a  Training  System 

A  Distributed  Multi-Architecture 
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C2SIM  Overlay  issues 

Stakeholders  include  both  C2  and  simulation  communities 

►  C2  system  lifecycles  duration 
Time  management 

►  Preparation  of  scenario  to  initialize  the  federation 

°  Scenario  and  conceptual  model 
°  Entities/objects 
°  Event  timelines 

°  Geographical  and  natural  environment 

End-users’  perception  of  federation  execution 

°  Report  message  processing 
°  Order  /  request  message  processing 

►  Analysis  of  federation  execution 

►  C2SIM  architecture,  infrastructure  services  and  data  exchange 
model 

9  Main  issues 
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Recommendations 
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Recommendations 

►  Use  SINEX  Process  for  Technical  Interoperability 
Standard  Development 

►  Use  SINEX  for  C2SIM  Interoperability  Standard 

►  Build  on  experience  of  NATO  Technical  Activities 

°  Prototype  and  user  test  before  standardizing 

►  Complete  an  open  source  SINEX  toolset 
°  Including  ontology  standards  (OWL,  RDF) 

►  Continue  C2SIM  DSEEP  overlay  development 

“  Elaborate  on  issues  already  identified 
n  archit0ctur0 
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Conclusions 
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Conclusions 


►  MSG-085  has  produced  a  wealth  of  experience  for  C2SIM 

►  Among  the  most  promising  of  these  is  the  SINEX  process 
that  promises  to  create  a  modular,  extensible  process  for 
standardizing  C2SIM  interfaces,  based  on  UML/MDA  and 
transformation  products 

►  The  draft  C2SIM  DSEEP  Overlay  captures  experience, 
lessons  identified  and  proposes  solutions  to  engineer  and 
execute  C2SIM  federations.  Additional  work  is  needed  to 
finalize  it  and  to  define  a  C2SIM  reference  architecture 
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SINEX  Background 

►  SINEX  draws  on: 

»  MIP  Modular  Enterprise  Architecture  Interoperability 
Solution  (Lang,  Gerz,  Meyer,  Sim  201 1) 

o  SDF  which  in  turn  builds  on  work  by  the  US  Intelligence 
community 

►  MIP  leverages  MDA  approach  using  a  PIM/LDM 

►  SDF  centers  on  LDM  while  maintaining  a  strong 
connection  with  stakeholder  requirements 

►  Transforms  are  used  to  derive  products  from  the 
SINEX  LDM  satisfying  requirements  for: 

»  Use  MIM  as  primary  source  of  vocabulary 
o  Extensibility 


